| Original author(s) | Red Hat |
|---|---|
| Developer(s) | Community[1] |
| Stable release | 4.9.0 / March 2, 2011 |
| Operating system | GNU/Linux, Unix-like |
| Type | Package management |
| License | GNU General Public License |
| Website | http://rpm.org/ http://rpm5.org/ |
RPM Package Manager (RPM) is a package management system.[2] The name RPM variously refers to the .rpm file format, files in this format, software packaged in such files, and the package manager itself. RPM was intended primarily for GNU/Linux distributions; the file format is the baseline package format of the Linux Standard Base.
While RPM was originally written in 1997 by Erik Troan and Marc Ewing[3] for use in Red Hat Linux, RPM is now used in many GNU/Linux distributions. It has also been ported to some other operating systems, such as Novell NetWare (as of version 6.5 SP3) and IBM's AIX as of version 4.
Whereas an RPM typically contains the compiled version of the software, an SRPM contains either the source code corresponding to that RPM or the scripts of a non-compiled software package.
Originally standing for Red Hat Package Manager, RPM now stands for "RPM Package Manager", a recursive acronym.
Contents |
For a system administrator performing software installation and maintenance, the use of package management rather than manual building has advantages such as simplicity, consistency and the ability for these processes to be automated and non-interactive.
A typical RPM repository (the place where the packages are made available publicly) contains thousands of free applications.
Features of RPM include:
Packages may come from within a particular distribution (for example Red Hat Linux) or be built for it by other parties (for example RPM Fusion for Fedora).[4] Circular dependencies among mutually dependent RPMs (so-called "dependency hell") can be problematic;[5] in such cases a single installation command needs to specify all the relevant packages.
There are several front ends to RPM that ease the process of obtaining and installing RPMs and in resolving their dependencies. These include:
Working behind the scenes of the package manager is the RPM database, stored in /var/lib/rpm. It uses Berkeley DB as its back-end. It consists of a single database (Packages) containing all of the meta information of the installed rpms. Multiple databases are created for indexing purposes, replicating data to speed up queries. The database is used to keep track of all files that are changed and created when a user (using RPM) installs a package, thus enabling the user (via RPM) to reverse the changes and remove the package later. If the database gets corrupted (which is possible if the RPM client is killed), the index databases can be recreated with the rpm --rebuilddb command.[8]
Whilst the RPM format is the same across different Linux distributions, the detailed conventions and guidelines may vary across them.
An RPM is delivered in a single file, normally in the format:
such as:
Source code may also be distributed in RPM packages; the architecture part is specified as <src>:
RPMs with the noarch.rpm extension refer to packages which do not depend on a certain computer's architecture. These include graphics and text for another program to use, and programs written in interpreted programming languages such as Python programs and shell scripts.
The RPM contents also include a package label, which contains the following pieces of information:
The package label does not necessarily need to match the name of the file.
Libraries are distributed in two separate packages for each version. One contains the precompiled code for use at run-time, while the second one contains the related development files such as headers, etc. Those packages have "-devel" appended to their name field. The system administrator should ensure that the versions of the binary and development packages match.
The format is binary and consists of four sections:[2]
The "Recipe" for creating an RPM package is a spec file. Spec files end in the ".spec" suffix and contain the package name, version, RPM revision number, steps to build, install, and clean a package, and a changelog. Multiple packages can be built from a single RPM spec file, if desired. RPM packages are created from RPM spec files using the rpmbuild tool.
Spec files are usually distributed within SRPM files, which contain the spec file packaged along with the source code.
A typical RPM is pre-compiled software ready for direct installation. The corresponding source code can also be distributed. This is done in an SRPM, which also includes the "SPEC" file describing the software and how it is built. The SRPM also allows the user to compile, and perhaps modify, the code itself.
A software package may contain only scripts that are architecture-independent. In such a case only an SRPM may be available; this is still an installable RPM.
As of June 2010[update], there are two versions of RPM in development – one led by the Fedora Project and Red Hat, and the other by a separate group led by a previous maintainer of RPM, a former employee of Red Hat.
The rpm.org community's first major code revision was in July 2007; version 4.8 was released in January 2010, and 4.9 in March 2011.
This version is used by distributions such as Fedora, Red Hat Enterprise Linux, SUSE's openSUSE and SUSE Linux Enterprise, CentOS and formerly Mandriva (only for 2009.0 - 2010.2).
The RPM maintainer since 1999, Jeff Johnson, continued development efforts together with participants from several other distributions. RPM version 5 was released in May 2007.
This version is used by distributions such as Unity Linux, Wind River Linux and cAos Linux, and also by the OpenPKG project which provides packages for other common UNIX-platforms. Mandriva has currently switched to it for their development branch, with 2011.0 becoming its first release using it [10]. ArkLinux also announced intention to move to RPM5 for its next release.
|
|||||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||